Code modification of rule-based implementations

ABSTRACT

Code compatibility provisions are provided. These may include identifying coding that is incompatible with a rule-based environment, searching replacement code solutions for compatible code and identifying a replacement code solution, manipulating the identified incompatible code using the identified replacement code solution, and, after manipulating the incompatible code with the replacement code solution, loading the services across a rule-based environment.

BACKGROUND

The present invention relates to application code implemented in arule-based environment. More specifically, the dynamic analysis andmodification of application code run in a rule-based environment such asa server cluster network environment.

Application servers are regularly grouped together such that theyprovide redundancy and scalability for the applications running thereonand for the clients accessing and using the applications. In redundancysituations, a single server failure may be imperceptible to a clientusing an application as client services may be transferred from thefailed server to a fully functioning server. In scalability situations,the addition of single clients or groups of clients can lead to serveroverload, so additional servers may be brought online to accommodatepeaking or increased workloads associated with additional client work.In this situation as well, the change in server status may beimperceptible to a client.

Applications running in multiserver environments have specific demandsplaced on them. These may include maintaining session persistence,accounting for common states, providing security, and other factors.

Embodiments of the invention may be directed to rule modifications forapplications run in rule-based environments, such as multiserverenvironments, when the applications may not have been previouslyintended for such an environment. Embodiments may also be directed toaccommodate special or unique demands of multiserver environments orother rules-based environments. Methods, procedures, articles ofmanufacture, and devices embodying the invention may analyze applicationcode and provide for adjustments to the code. These adjustments may bein an automatic fashion, a manual fashion, or both.

BRIEF SUMMARY

Methods, apparatus, and articles of manufacture may be included inembodiments of the invention. These embodiments can includemanufactures, computers, and methods that analyze application code andprovide adjustments in an automatic and/or manual fashion when loadingthe code for a rule-based environment.

The various exemplary instructions, methods, and steps may include:identifying coding that is incompatible with a server clusterenvironment; searching replacement code solutions for code compatiblewith a server cluster environment and identifying a replacement codesolution; manipulating the identified incompatible code using theidentified replacement code solution; and, after manipulating theincompatible code with the replacement code solution, loading theservices with the now compatible code, across a cluster serverenvironment. In embodiments the identified code and the replacement codemay be bytecode.

Additional instructions and steps in embodiments may include seekingreplacement code solutions from a different source after searchingreplacement code solutions for code but failing to identify areplacement code solution. In certain embodiments, the different sourcemay be a system administrator. The additional instructions and steps mayalso include developing a replacement code solution by calling andapplying a code compatibility algorithm.

Still further, additional embodiments may also include providing code,identified as incompatible, to a system administrator and checking forinstructions to disregard a replacement code solution for the codeidentified as incompatible to the system administrator.

As provided and taught herein, these and other embodiments of theinvention are possible.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 shows clients, servers, and networks, as may be employed inaccord with embodiments of the invention.

FIG. 2 shows a method as may be employed while loading an application ina rule-based environment in accord with embodiments of the invention.

FIG. 3 shows a method as may be employed while loading an applicationacross multiple servers in accord with embodiments of the invention.

FIG. 4 shows a networked system as may be employed when loading orrunning multiserver applications in accord with embodiments of theinvention.

DETAILED DESCRIPTION

Embodiments include systems, methods, apparatus, and articles ofmanufacture that selectively analyze and update applications beingloaded and run in a rule-based environment, such as a cluster ormultiserver environment. In embodiments, an application which may or maynot be regarded as having been vetted for use by a cluster of servers,may be analyzed and considered during load time for anomalies that mayaffect the efficiency or efficacy of the application to be run in amultiserver environment. This vetting may include, during the loadingprocess, considering and analyzing compiled code, flagging possiblyproblematic compiled code, making provisions to repair the flaggedcompiled code, repairing the compiled code, and loading the updatedapplication across a cluster of servers. The provisions to repair theloading code may be both automatic and manual. In a java environment,the analysis and modification may be done to bytecode.

The automatic provisions may include searching for and identifying knowninconsistencies or incompatibilities in code that act to undermine theability of the code to run in a multiserver environment. Theseinconsistencies can include a failure to track and store sessionproperties for clients, making calls outside of certain objects orclasses available to a server, and other problems as well. In oneexample, when a state is maintained between provided services, anincompatible application may have difficulty maintaining that state iftwo different servers are providing the services. With this potentialconflict, as well as with others, a code revision engine may be used torewrite or replace the incompatible code such that the code wouldmaintain state between service runs.

In embodiments, a code revision engine resident on a server or elsewheremay be employed to automatically analyze and consider bytecode duringapplication loading processes. When the analyzed bytecode maintainsstate or otherwise runs in a manner inconsistent with a multiserverenvironment, the bytecode may be flagged and rewritten. Rewriting thecode may include selecting from stored replacement code at the coderevision engine or elsewhere, and supplementing or amending theincompatible code with the stored replacement code. In certainembodiments, some stored code or automatic metrics for rewritingincompatible code may not be available or feasible. In these situations,along with making feasible automatic code replacements, manualintervention may also be provided. Thus, in some embodiments,administrator intervention and automatic bytecode modification may eachbe used to have applications that were previously considered to besolely compatible with a single server environment, run in a multiserverenvironment.

In embodiments, such as those having a collection of web serviceimplementations, a web service container may be used to distribute theexecution load across a cluster of machines even if some of theimplementations might not have been written in a cluster friendly orcompatible manner. An example of this may surround the use of IBM'sWebsphere™ application, which allows for the distributive execution ofweb services and EJBs across a cluster to provide scalability. However,when this distribution is provided under the assumption that eachimplementation is properly designed for execution in a cluster, runningthe implementations may result in incorrect execution, corruptedinformation, or security violations. As a resolution, a masterapplication server may be used to analyze the implementation of theWebsphere™ services when they are loaded and dynamically apply bytecodemanipulation to fix the coding mistakes that would retard or prevent theservice from being clusterable.

In embodiments, services that have been implemented in a clustercompatible fashion may require no modification and may be deployed asis. Conversely, where services with incompatible practices are detected,they may be re-written when loaded to patch the incompatible code withknown solutions. Thus, in embodiments, a service that was writtenwithout following a set of clustering coding practices, may be deployedin a clustered or other rule-based environment.

FIG. 1 shows a system of servers, networks, clients, administrators, andfirewalls that may be employed in accord with embodiments of theinvention. As can be seen in FIG. 1, clients 130 may be connected toeach other and to a network 140. Administrator 150 may also be connectedto network 140. A firewall 125 may sit between server 120, servers 105,and storage 110. Firewalls may also be present between the administrator150 and the network 140 as well as between the clients 130 and thenetwork 140. Also, while not shown in FIG. 1, administrator 150 and theclients 130 may also have access to and may be connected with network115.

In embodiments, the primary server 120 may be loading a web applicationthat assists clients 130. In embodiments, the primary server 120 maycontain a dynamic code compatibility engine such that as the applicationis loaded by the primary server, the code engine may take steps toaccommodate having the application loaded onto and across secondaryservers 105. As the primary server loads the application, the codeengine may consider the code being loaded and when incompatible code isidentified, replacement code stored in network storage 110, may be usedto replace the incompatible code. This identification, query andreplacement may continue until the entire application is reviewed by thecode engine and each incompatibility has been replaced with substitutecode from the network storage 110. Once the substitutions are complete,the primary server 120 may finalize loading of the application across itand the secondary servers 105.

In this and other embodiments operating in an object oriented codeenvironment, the primary server may contain each of the classes requiredto execute each applicable service request. However, the server may seekto distribute some service execution to secondary machines to support alarger load or for other reasons. This distribution may include use ofpreviously programmed distribution services that apply knownmethodologies for delegating the execution of service requests tosecondary servers. This distribution may also include the use of APIsfor services to use and enable behavior in the cluster where theservices may include a distributed locking API and a distributed cacheAPI.

FIG. 2 shows a method as may be employed in accord with embodiments ofthe invention. The actions described herein are exemplary and mayinclude additional or fewer steps and may be performed in this as wellas other orders. In embodiments, as shown at 205, services may beidentified and considered for use across a cluster of servers. As theseservices are loaded, as shown at 210, they may be analyzed to identifycoding that is noncompatible with a server cluster or other rule-basedenvironment. As noncompatible code is identified, as shown at 215, codecluster patches may be identified and applied as solutions for theidentified noncompatible code. As shown at 220, the noncompatible codemay be manipulated such that they serve as patches and dynamic clusterrepairs for the noncompatible code. Having been modified, as shown at225, the cluster patches and fixes may be adjusted and optimized.Finally, as shown at 230, the loading of the application code maycontinue such that the services associated with the application, alongwith the patches and fixes, may be deployed across a cluster of machinesor servers.

FIG. 3 shows a method as may be employed in accord with embodiments ofthe invention. Shown at 305 of FIG. 3, a master server may receive theservice request and identify implementation methodology for the serviceto be run on the master server and secondary servers. As shown at 310,the master server may employ a custom class loader to access bytecode ofthe service request implementation. The bytecode may be presented to theclass loader of the master server, as shown at 315. Next, as shown at320, upon presentation of the bytecodes, it may be read in order to flagcode incompatibilities with the cluster server implementation. Ifincompatibilities are found, the server may apply bytecode manipulationto the incompatible classes being loaded, as shown at 330. Thismanipulation may include classifying the code incompatibility andsearching compatibility databases for known fixes to the classificationattributed to the incompatible code. If incompatibilities are not found,the application may be deployed by the master server to cluster serversas shown at 350.

As a server applies the bytecode manipulations at 330, the server maytrack whether or not each indentified incompatibility has been addressedand resolved. If each incompatibility has been addressed, as shown at335, then the application may be deployed by the master server tocluster servers, as shown at 350. If certain manipulations have not beenproperly employed or cannot be verified as having been properlyemployed, the server may flag these incompatible bytecode segments formanual manipulation.

Having received a flag or signal that manual intervention may berequired, an administrator, as shown at 345, may manipulate the flaggedincompatible code to make it compatible with a cluster-serverenvironment. Having made such a manipulation, the administrator mayalert the server that the code has been vetted and may be deemedcompatible. This action is shown at 350. Upon receiving such notice, theapplication may be deployed by the primary server to the secondaryservers. As such, in each of the three different scenarios, theapplication may be deployed from the primary server to the secondaryservers and, thus, loaded across a cluster of servers. This loading isreflected at 355.

In embodiments, when the primary server receives a service request itmay initially look up the implementation of that service. By using acustom class loader, the server may load and obtain access to thebytecodes of the implementation. When the bytecodes are presented to theclass loader of the server, the server may manually read and interpretthe bytecodes of the implementation to find cluster incompatible code.The server may then apply bytecode manipulation to the classes whencluster incompatible code is found, and that manipulation would act toremove incompatibilities in the code such that the code may bedeployable across the cluster.

As a specific example, where a service implementation consists of asingle method on a single class. A possible ‘addition’ service might begenerally implemented as follows:

public class Adder {   public int add (int first, int second) {   returnfirst + second;   } }

Interpreting the bytecodes for this service would reveal that it may beconsidered clusterable as the output of the service is dependent only onthe inputs to the service. Two calls with the same arguments will resultin the same value, and will not interact with each other. When theserver decides that it is clusterable, it could distribute that serviceto any secondary machines available without modification.

However, a different service might be implemented as follows:

public class Counter {   private int counter = 0;   public intgetValueAndIncrement( ) {     return counter++;   } }

Interpreting the bytecodes for this service, a code engine may find thatthis service is not cluster compatible as this service would only behaveconsistently if it was always executed in the same virtual machinebecause the service maintains state between service calls (the countervariable). If this code was distributed in a cluster the results frommultiple service calls would not be always increasing, but wouldsometime repeat and not proceed in order.

Thus, in embodiments, the code engine could potentially re-write thebytecodes to have the following changes:

public class Counter {  private SharedInteger counter =ApplicationServerAPI>.getSharedInteger(Counter.class, “counter”); public int getValueAndIncrement( ) {     returncounter.incrementAndReturn( );

Accordingly, details regarding how an integer reference is made may bereplaced with a shared integer object. This implementation may vary foreach application server, and could potentially vary based on thefeatures installed or the setup of a specific server.

In embodiments, the code engine may search for and employ substitutionsthat leverage current code solutions or revised code solutions given theenvironment that the application would be installed into. In morecomplex examples, the code engine embodying the invention may need todetect the code for maintaining state between service executions. Whenthe complexity of real service implementations results in no previouslystored solutions being available, or in inconclusive results as tocompatibility, users may be allowed to override code that is consideredcluster compatible such that complex but safe code may not be modified.When code is deemed not compatible by a user after being flagged aspossibly being incompatible and having no stored solution, a user basedsolution may be employed. Such a solution is set out in published U.S.patent application 20090064137.

FIG. 4 shows a primary server, secondary servers, a network, andclients, as may be employed in accord with embodiments. The primaryapplication server 410 is shown connected to network 440, which isin-turn connected to servers 450 and clients 425. As can be seen, theprimary application server 410 may contain a processing unit, systemmemory 412, interfaces 413, serial port interfaces 414, an I/O adapter415, a hard drive 419, removable storage 418, and a network adapter 417.Each of these components may themselves be connected to each other via abus 416. Code to be implemented by the primary application server 410may be stored in both the system memory 412 and the hard drive 419. Ascan be seen at 420, the code in memory may include operating systemapplications, the bytecode engine, plug-ins, and data, which can includethe code cluster patches.

While it is understood that process software embodying the invention maybe deployed by manually loading directly in the client, server and proxycomputers via loading a storage medium such as a CD, DVD, etc., theprocess software may also be automatically or semi-automaticallydeployed into a computer system by sending the process software to acentral server or a group of central servers. The process software isthen downloaded into the client computers that will execute the processsoftware. Alternatively the process software is sent directly to theclient system via e-mail. The process software is then either detachedto a directory or loaded into a directory by a button on the e-mail thatexecutes a program that detaches the process software into a directory.Another alternative is to send the process software directly to adirectory on the client computer hard drive. When there are proxyservers, the process will, select the proxy server code, determine onwhich computers to place the proxy servers' code, transmit the proxyserver code, then install the proxy server code on the proxy computer.The process software will be transmitted to the proxy server then storedon the proxy server.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the invention. Asused herein, the singular forms “a,” “an” and “the” are intended toinclude plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specific thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operation, elements,components, and/or groups thereof.

Embodiments may be implemented as a computer process, a computing systemor as an article of manufacture such as a computer program product ofcomputer readable media. The computer program product may be a computerstorage medium readable by a computer system and encoding a computerprogram instructions for executing a computer process.

The description of the present invention has been presented for purposesof illustration and description, but is not intended to be exhaustive orlimited to the invention in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill without departingfrom the scope and spirit of the invention. The embodiments were chosenand described in order to best explain the principles of the inventionand the practical application, and to enable others of ordinary skill inthe art to understand the invention for embodiments with variousmodifications as are suited to the particular use contemplated.

1. An article of manufacture comprising: a non-volatile computerreadable medium, the computer readable medium storing instructionsthereon for analyzing code being provided across a cluster of servers,the instructions, which when executed, comprising: during the process ofloading services, identifying coding that is incompatible with a servercluster environment; searching replacement code solutions for codecompatible with a server cluster environment; identifying a replacementcode solution; manipulating the identified incompatible code using theidentified replacement code solution; and after manipulating theincompatible code with the replacement code solution, to render theincompatible code compatible, loading the services, with the nowcompatible code, across a cluster server environment.
 2. The article ofclaim 1 wherein the identified code is bytecode and wherein thereplacement code is bytecode.
 3. The article of claim 1 storinginstructions, which when executed, further comprise: after searchingreplacement code solutions for code and failing to identify areplacement code solution, seeking replacement code solutions from adifferent source.
 4. The article of claim 3 wherein the services areloaded onto a server and wherein the different source is a serveradministrator.
 5. The article of claim 1 storing instructions, whichwhen executed further comprise: developing a replacement code solutionby calling and applying a code compatibility algorithm.
 6. The articleof claim 1 storing instructions, which when executed, further comprise:providing code, identified as incompatible, to a system administrator;and checking for instructions to disregard a replacement code solutionfor the code identified as incompatible to the system administrator. 7.The article of claim 1 wherein identifying coding includes consideringbytecode and wherein the bytecode is presented to the class loader of aprimary server.
 8. A method comprising: during the process of loadingservices on a server, identifying coding that is incompatible with aserver cluster environment; searching replacement code solutions forcode compatible with a server cluster environment; identifying areplacement code solution; manipulating the identified incompatible codeusing the identified replacement code solution; and after manipulatingthe incompatible code with the replacement code solution, to render theincompatible code compatible, loading the services, with the nowcompatible code, across a cluster server environment.
 9. The method ofclaim 8 wherein the identified code is bytecode and wherein thereplacement code is bytecode.
 10. The method of claim 8 furthercomprising: after searching replacement code solutions for code andfailing to identify a replacement code solution, seeking replacementcode solutions from a different source.
 11. The method of claim 10wherein the different source is a system administrator.
 12. The methodof claim 8 further comprising: developing a replacement code solution bycalling and applying a code compatibility algorithm 11 wherein thecommon traits for grouped attributes include a shared range of timerequired to serialize the grouped attribute.
 13. The method of claim 8further comprising: providing code identified as incompatible to asystem administrator; and checking for instructions to disregard areplacement code solution for the code identified as incompatible to thesystem administrator.
 14. The method of claim 8 wherein identifyingcoding includes considering bytecode and wherein the bytecode ispresented to the class loader of a primary server.
 15. A computercomprising: a non-volatile computer readable medium, the computerreadable medium storing instructions thereon for analyzing code beingprovided across a cluster of servers, the instructions, which whenexecuted, comprising: identifying coding, during the process of loadingservices, that is incompatible with a server cluster environment;searching replacement code solutions for code compatible with a servercluster environment; identifying a replacement code solution;manipulating the identified incompatible code using the identifiedreplacement code solution; and after manipulating the incompatible codewith the replacement code solution, to render the incompatible codecompatible, loading the services, with the now compatible code, across acluster server environment.
 16. The computer of claim 15 wherein theidentified code is bytecode and wherein the replacement code isbytecode.
 17. The computer of claim 15 storing instructions, which whenexecuted, further comprise: after searching replacement code solutionsfor code and failing to identify a replacement code solution, seekingreplacement code solutions from a different source.
 18. The computer ofclaim 17 wherein the different source is a system administrator.
 19. Thecomputer of claim 15 storing instructions, which when executed furthercomprise: developing a replacement code solution by calling and applyinga code compatibility algorithm.
 20. The computer of claim 15 storinginstructions, which when executed, further comprise: providing codeidentified as incompatible to a system administrator; and checking forinstructions to disregard a replacement code solution for the codeidentified as incompatible to the system administrator.